1. Field of the Invention
The present invention relates, generally, to content delivery networks and, in preferred embodiments, to systems and methods for intelligent fetch and delivery of Web content to improve content delivery services.
2. Description of the Related Art
Web performance is a key point of differentiation among content providers. Crashes and slowdowns within major Web sites demonstrate the difficulties companies face in trying to deal with high Web traffic. As Internet backbone technologies have developed, many innovations in the area of service management have improved bandwidth and Web content retrieval response time. These improvements to infrastructure, however, cannot solve traffic problems at all points within the Internet.
For example, assume in FIG. 1 that an end user 12 in a network 14 in Japan requests access to a page from a Web site 16 in a network 18 the United States. The request must pass through several gateways 20, 78, and 80 before reaching Web site 16. Although Web site 16 may have large bandwidth (the ability to rapidly communicate large quantities of data), the gateways connecting the network 14 in Japan to the network 18 in the United States may be slow, and thus, when end user 12 attempts to access the page from Web site 16, the gateways may create a bottleneck. Such gateway bottlenecks may result in the access time for one page of data being on the order of 10 seconds or more. Because of the gateway bottlenecks, and because there are many uncertainties along the Internet paths from end user 12 to/from the Web site 16, content delivery networks or systems are now being developed.
Fundamentally, content delivery systems may be designed and deployed for at least two major purposes; one is to achieve load balancing, and the other is to reduce response time. A content delivery system may be implemented using a high speed dedicated line to deliver content while bypassing all gateways or reducing the number of Internet gateways in the transmission path. However, such a dedicated network is expensive and cannot be deployed for all networks. Another approach to implementing content delivery systems is through the use of intelligent caching, mirroring, proxy servers, or other techniques which redirect end users to available servers that contain the desired content and are close to or easily accessible by the end users to ensure fast response time. With some of the traffic redirected, traffic surges will decrease and end users benefit from faster response time. The term generally used for the architecture and functionality of such networks or systems is content delivery services (CDS).
FIG. 2 illustrates an overview of a conventional Web content delivery and caching scheme 22. It should be understood that FIG. 2 is related to FIG. 1 in that the proxy server 28 of FIG. 2 is located at some point between the end user 12 and original Web site 16 of FIG. 1. When a user (e.g. user 1; see reference character 24) attempts to access a page (e.g. index.html) from a Web site (e.g. Web site 1; see reference character 26), the browser of user 1 will first send a request to a domain name server (DNS) to find the Internet Protocol (IP) address corresponding to the domain name of Web site 1. Although not shown in FIG. 2, it should be well understood by those skilled in the art that a network of DNSs exists to locate the IP addresses of requested domain names.
After the browser of user 1 receives the IP address of Web site 1, the browser will attempt to access the page from proxy server 28. Proxy server 28 will then determine if the desired page is in the cache 30 of proxy server 28. If the desired page is in cache 30, proxy server 28 will simply deliver the content in cache 30 to user 1 without attempting to access the page from the original Web site (Web site 1). If the desired page is not in cache 30, proxy server 28 will send a request to Web site 1 to fetch index.html (text only).
After the browser of user 1 receives index.html, the browser will parse the page and issue additional requests to fetch embedded objects such as images and icons. However, proxy server 28 will first receive these requests and determine if the embedded objects are available in cache 30. If the desired objects are in cache 30, proxy server 28 will simply deliver the objects in cache 30 to user 1 without attempting to fetch the objects from the original Web site (Web site 1). If the desired objects are not in cache 30, proxy server 28 will send requests to the appropriate Web sites to fetch the objects.
Traffic (i.e. data flow) can be recorded in a log file 32 in proxy server 28. Such a log file may contain the IP addresses of the originators of requests, the URLs of objects fetched, a time stamp for each action, and the like. It should be noted that a proxy server 28 is usually shared by many users so that the contents of cache 30 can be accessed by users with similar interests. Thus, for example, if user 1 accesses a page and that page is stored in cache 30, when user 2 (see reference character 90) requests the same page, proxy server 28 can simply provide the page stored in cache 30 to user 2.
However, delays may still occur during the fetching of embedded objects because of the high processing overhead associated with each fetch. For example, a typical Web page may consist of images and icons, which are essentially small images. The data associated with an icon may be transferred using just a few data packets. However, in any transfer there is processing overhead in the form of commands to open and close the connection. This processing overhead may comprise six or seven data packets.
FIG. 3 illustrates the data packets involved in the transfer of an icon. First, a user 34 sends a SYN request 36 to a server 38 using a data packet to establish a connection. In response, server 38 will send a SYN acknowledgment message 40 back to user 34 using another packet. User 34 will then acknowledge receipt of that packet by sending an acknowledgment 42 back to server 38 using yet another packet. Three packets are therefore required to open a connection. Once the connection is open, user 34 may send a “get-icon” request 44 to server 38 using another packet. Server 38 will then send multiple packets 46, 82, and 84 back to user 34 containing the payload or contents of the icon. Once the data transfer is complete, server 38 sends a FIN message 48 back to user 34 using another packet. FIN message 48 indicates that server 38 wants to terminate the connection. In response, user 34 sends an acknowledgment message 50 back to server 38 using one packet. User 34 then sends a FIN message 52 back to server 38 using one packet, and server 38 acknowledges receipt of this packet by an acknowledgment message 54 back to user 34. Thus, a total of four packets are needed to close the connection. The example of FIG. 3 illustrates that icon transfer can be very inefficient, for seven packets of overhead are needed for just two or three packets of content. This inefficiency is compounded because on a typical Web page there are many icons.
In addition, because a Web page may require the fetching of multiple images, and because servers may impose a fixed limit of connections per user, not all images may be simultaneously fetched. An unscheduled fetching of multiple images may result in a user viewing incomplete images for long periods of time. However, it may be important for a user to see some full images within a reasonable time in order to click on that image to further navigate the Internet. From the user's point of view, it may be desirable to see complete embedded objects as early as possible so that the user can have a better idea about the content of the web page. This is especially applicable to small images such as icons, for a user may not be able to understand the content of a Web page based on a portion of an already small image.